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Abstract. The timed-based automata model, introduced by Alur and 
Dill, provides a useful formalism for describing real-time systems. Over 
the last two decades, several dense-time model checking tools have been 
developed based on that model. The paper considers the verification of 
real-time distributed commit protocols using dense-time model checking 
technology. More precisely, we model and verify the well-known timed 
two phase commit protocol in three different state-of-the-art real-time 
model checkers: UPPAAL, Rabbit, and RED, and compare the results. 



1 Introduction 

Real time systems are currently being used in many safety critical applications 
such as computer-controlled medical devices, air traffic control systems, and 
real-time database systems. Ensuring the correctness of real-time systems is a 
challenging task. This is mainly because the correctness of real-time systems 
depends on the actual times at which events occur. Moreover, these systems 
involve interactions of a number of concurrent components that have a high 
level of complexity. Such interactions might lead to many subtle or undesirable 
situations if they are not considered carefully. Hence, real-time systems need to 
be rigorously modeled and verified in order to formally prove their correctness 
with respect to the desired properties. It is well-known that only formal methods 
of verifications can guarantee that the system meets its desired properties. One 
of the well-known formal verification techniques is the model checking technique 

Model checking is an automated method for verifying finite state systems. 
Model checking has been successfully used to find non-trivial errors in hardware 
designs, distributed systems, and security protocols. Applying model checking 
to prove the correctness of a system design consists of three formal independent 
steps, which are modeling, specification, and verification. Model checking uses 
a variety of sophisticated heuristics and symbolic implementation techniques to 
check that a logical formula holds in the given system design. Typically, formulas 
are expressed using logics such as temporal logic, belief logic, or epistemic logic, 
while the system will be expressed as a set of states (finite number of states) 
and a set of transitions. When the system fails to meet a desired property, the 
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model checker produces a counterexample that helps to identify the source of 
the error in the system design. 

Because of time constraints in real-time systems, traditional model checking 
approaches based on finite state automata and temporal logic are not suffi- 
cient. Since they can not capture the time requirements of real-time systems 
upon which the correctness of these systems relies. Developing formal methods 
for verifying real-time systems has been an active area of research. Several re- 
searchers have proposed different modeling formalisms for describing real-time 
systems such as timed transition systems [H], timed I/O automata [T7], and 
timed automata model [4|. Although a number of formalisms have been pro- 
posed, the timed automata model of Alur, Courcoubetis, and Dill [3] has become 
the standard. In fact the majority of the existing dense-time model checking 
tools in the literature are based on this model. Examples include UPPAAL [7], 
KRONOS [13], RED [25], and Rabbit [9]. 

In this paper we consider the application of dense-timed model checking to 
real-time distributed commit protocols. In general, commit protocols can be clas- 
sified into conventional (non-real-time) commit protocols and real-time commit 
protocols. In conventional commit protocols such as the classical two phase com- 
mit protocol (2PC) [5], processes need to coordinate with each other in order 
to reach a common decision on whether or not to commit the transaction, but 
there is no strict or hard time constraints on agreement. On the other hand, in 
real-time commit protocols, all processes should commit the transaction before 
the deadline expires or all of them should abort immediately upon deadline ex- 
piry. So real-time transaction protocols should satisfy data consistency as well as 
they must satisfy timing constraints associated with transaction. Model checking 
has frequently been used to verify conventional commit protocols 20 6 15 21 . 
In comparison, little work has been done on model checking real-time commit 
protocols. 

In this contribution, we conduct a comparative study of a number of model 
checking tools, based on a variety of approaches to representing real-time sys- 
tems. We have selected one specific practical real-time commit protocol, the 
timed two phase commit protocol (12) . implemented it in quite different 'dense' 
timed model checkers, and verified its relevant properties. Specifically, we con- 
sider the model checkers UPPAAL, Rabbit and RED. UPPAAL deals with the 
logic of TCTL |2j using difference bound matrices (DBM) based algorithm. Rab- 
bit is a model checker based on timed automata extended with concepts for 
modular modeling and performs reachability analysis using BDD based algo- 
rithm. RED is a model checker with dense-time models based on CRD (Clock- 
Restriction Diagrams) algorithm. Analysing the protocol using these tools re- 
quires us to learn the modelling and the specification language of the tools, 
which allows us to discover the capabilities and the limitations of these tools. 
Moreover, it allows us to compare the efficiency and the performance of the 
algorithms and data structures implemented in these tools. 

All three implementations were carried out on the same verification server 
in order to obtain results that can be used to compare the performance of these 



tools. RED outperformed both UPPAAL and Rabbit in terms of performance, 
scalability, and expressivity of its specification language. Unlike UPPAAL and 
Rabbit, RED supports full TCTL language and allows verifying formulas with 
nested temporal modalities. Heuristics used in RED allowed us to verify the 
protocol for a large number of processes and great number of clocks. During our 
analysis we have been able to discover some interesting conclusions about the 
protocol. In particular, we find that the central property of the protocol, the 
data consistency property, might be temporarily broken during the execution 
of the protocol. However, when the protocol does terminate, we find that the 
consistency is preserved. 

The structure of the paper as follows. Section [5] describes the concept of a 
real-time distributed system and gives an informal description for the timed two 
phase commit protocol. Section [3] describes briefiy the theory of timed automata 
and the timed temporal logic. Sections|4]to[6]are dedicated to the implementation 
of the protocol in the model checkers, respectively, UPPAAL, Rabbit, and RED. 
We discuss correctness conditions of the protocol in Section [T] In Section [5] we 
formalise the specifications of the protocol in the input language of each model 
checker. Section [3] discusses the verification results of the protocol. Section [TU] 
compares the performance results of the three tools. We discuss related work in 
Section [TT] and conclude in Section [T^l 



2 Real-time Distributed Transaction Protocols 

Real-time database systems are transaction processing systems that are designed 
to handle transactions that have real-time constraints (deadlines). These sys- 
tems can be said to be failed if they can not complete within their deadline. 
In distributed real-time transaction protocols, all processes should commit the 
transaction before the deadline expires or all of them should abort immediately 
upon deadline expiry. There are many database applications that have real-time 
constraints. Examples include web-based auctions, medical records, reservation 
systems, and banking information systems. Several commit protocols have been 
proposed to handle real-time transactions such as Timed Two Phase Commit 
(T2PC) protocol [H], PROMPT commit protocol [H], the deadline-driven con- 
flict resolution protocol J^, and the double space commit protocol [35]. This 
paper analyses the T2PC protocol as a case study on real-time commit protocols 
using three state-of-the-art dense-timed model checkers. 

The T2PC protocol aims to maintain data consistency of all distributed 
database systems as well as having to satisfy the time constraints of the trans- 
action under processing. The protocol is mainly based on the well-known two 
phase commit (2PC) protocol, but it incorporates several intermediate deadlines 
in order to be able to handle real-time transactions. We describe first the basic 
2PC protocol (without deadlines) and then discuss how it can be modified to be 
used for real-time transactions. The 2PC protocol can be summarised as follows 



A set of processes {pi, ..,Pn} prepare to involve in a distributed transaction. 
Each process has been given its own subtransaction. One of the processes wiU act 
as a coordinator and aU other processes are participants. The protocol proceeds 
into two phase. In the first phase (voting phase), the coordinator broadcasts a 
start message to all the participants, and then waits to receive vote messages 
from the participants. The participant will vote to commit the transaction if all 
its local computations regarding the transaction have been completed success- 
fully; otherwise, it will vote to abort. In the second phase (commit phase), if the 
coordinator received the votes of all the participants, it decides and broadcasts 
the decision. If all the votes are 'yes' then the coordinator will decide to commit 
the result of the transaction. However, if one vote said 'no', then the coordinator 
will decide to abort the transaction. After sending the decision, the coordinator 
waits to receive a COMPLETION messages from all the participants. The pro- 
tocol terminates whenever the coordinator receives all COMPLETION messages 
successfully. 

For the above 2PC protocol, let S be the absolute start time of the protocol, 
and D be the absolute deadline. For each of the participants, let ti be the max- 
imum time needed to receive a decision message from the coordinator, perform 
the commit or abort action, and send a completion message to the coordinator. 
We will call the largest of all the ti the Tmax- For the coordinator, let Td be the 
maximum amount of time needed to receive the votes of all the participants, 
process them, and make a decision; and Tf be the maximum amount of time 
needed to receive the completion signal from all the participants. We will use 
A to denote the bound on execution of send, and A* to denote the bound on 
execution of broadcast (send-all). 

The following intermediate deadlines have been added to the basic 2PC pro- 
tocol in order to be able to handle real-time transactions [T^ : 

— Dp = D — A — Tf. deadline for sending a completion message by a participant. 
Each participant must complete the commit or abort action and send the 
completion message within A time unit, so that the coordinator still has 
enough time to process it with at most Tf time units before the expiry of D. 

— DEC = Dp — Tmax — A*: deadline for sending a decision by the coordinator. 
This represents the maximum message delay for the broadcast decision to 
arrive the participant. 

— V = DEC — A — Td'. deadline for a participant to vote. The participant must 
vote and send the vote to the coordinator before the DEC timer expires. 

— [LSTi, Dp]: the time interval during which Pi requests a reserve of ti time 
units of resources needed to perform the decided-upon action. 

Note that the correctness of the T2PC protocol depends mainly on the way we 
select the values of the above timing parameters. In particular, the coordinator 
should choose the value of D to be sufficiently long to allow the participants 
to receive the start message and return the completion message in time for the 
coordinator to determine the result. The correctness of the protocol depends 
also on a condition that a fair scheduling policy is imposed, this condition is 



necessary in order to avoid situations in which some participants may miss the 
deadline if they schedule to execute until after the deadline D. 

The basic 2PC protocol (without deadlines and timers) has been extensively 
studied and analysed using model checking j20l6ll5l2T| . However, no work has 
been done on model checking the real-time version of the protocol (T2PC). 
Of course, analysing real-time commit protocols is much harder than analysing 
conventional commit protocols since real-time protocols usually involve many 
timers in their design which increase the algorithmic complexity of the analysis. 

3 Timed Automata and Real-time Temporal Logic 

In this section we describe briefly the semantics of timed automata and then 
discuss the syntax and the semantics of TCTL logic. 

Timed automata are an extension of the classical finite state automata with 
clock variables to model timing aspects [3]. The theory of timed automata pro- 
vides a powerful formalism to model and verify real-time systems. Systems whose 
correctness depend on strict timing constraints such as response time, deadlines, 
communication delay can be easily described using the timed automata model. 
Research on timed automata theory has been an intensive field of research since 
it was introduced in 1990. Although a number of formalisms have been proposed 
to model timed systems, the timed automata model has become the standard. 
We therefore find that the majority of the existing real-time model checking 
tools in the literature are based on this model. Examples include UPPAAL [7], 
KRONOS [S], RED [25], and Rabbit [9]. 

We begin by briefly reviewing some basic definitions of the timed automaton 
model proposed by Alur and Dill ^ and the transition systems that underlies 
its semantics. 

Definition 1. Given a set X of clock variables, the set^{X) of clock constraints 
(j) is defined by the following grammar 

(f> :■= X ^ c \ A (j)2 

where x e X , c eN, and {<, <, =, >, >}. □ 

A clock interpretation v for a set X is a mapping from X to M+ where M+ 
denotes the set of nonnegative real numbers including zero. 

Definition 2. A timed automaton A is a tuple (S, S, Sq, X, E), where 

— S is a finite set of actions. 

— S is a finite set of states. 

— So is a finite set of initial states. 

— X is a finite set of clocks. 

— ECSxSxSx 2^ X <?(C) is a finite set of transitions. An edge (s, s , a, A, a) 
represents a transition from state s to state s after performing action a. The 
set A C C gives the clocks to be reset with this transition, and a is a clock 
constraint over C . □ 



The semantics of a timed automaton (S, S, Sq, X, E) is defined by associating 
a transition systems with. it. With each transition a clock constraint is associated. 
The transition can be taken only if the clock constraint on the transition is 
satisfied. There are two basic types of transitions: 

1 . delay transitions that model the elapse of time while staying at some location, 

2. action transitions that execute an edge of the automata. 

A state or configuration consists of the current location and the current 

values of clocks. The initial state is [IotVq] where vq{x) — for all x & X. K 
timed action is a pair (i, a) where a G 17 is an action performed by an Automata 
A after t G M"*" time units since A has been started. Complex systems can be 
described as a set of timed automata executing in parallel. A network of timed 
automata can be expressed as A = {Ai, A2) where Ai is a timed automaton. 

Definition 3. An execution of a timed automata A — {S, S, So,X,E) with an 
initial state (/q, ^o) over a timed trace — (^i, oi), (^2, 0,2), (ts, 03), .. is a sequence 
of transitions: 

(to, Wo) — > — > {h,vi) > — > {h,V2) — > — > {h:V3)... 

satisfying the condition ti = ti-i + di for all i > 1. □ 

The transition system in timed automata is infinite as clocks are real- valued, 
therefore timed automata models can not be directly model checked. However, 
there exist methods to reduce the infinite state space of timed systems to finite 
space while preserving properties of interest. Examples of abstraction methods 
include the region [3] and zone [1] methods. 

Analysing the behaviour of timed systems requires to verify whether they 
satisfy the timing properties that they are supposed to satisfy. Verification tech- 
niques based on classical temporal logic are inadequate for real-time systems 
since they lack the expressiveness to capture quantitative temporal constraints 
upon which the correctness of these systems relies. An easy and effective way 
to allow the verification of dense-time properties is to add bounds in the CTL 
temporal operators. The extended logic is called TCTL [2]. The expressive power 
of TCTL is similiar to the CTL but it incorporates time-constrained modalities 
in order to specify timing properties. Using this logic we can specify properties 
like event ei has to occur after 10 time units after event 62 occurred. The syntax 
of TCTL logic can be given by the following definition. 

Definition 4. (Syntax of timed computation tree logic) Let A be a timed 
automaton with set of clocks X and set of propositions Prop, and let Z be a set of 
clocks disjoint with X . The set of formulas of TCTL is defined by the following 
grammar: 

^ ::= p I </) I -V I V'l V I Eli^i Uij2] \ A[i;i t/V'2] 



where p £ Prop, z G Z, and (j) is a clock constraint as defined in Definition 1. □ 



Before we discucss the formal semantics of TCTL, let us introduce some 
notations. A position to of a run r G TZa is a pair G N x M+. The set of 

positions of the form (i, a) characterizes the set of states through which the run 
r passes while time flows from state qi to state qi+i- We use the notation ~ to 
refer to one of the following relations {<,<,=,>,>}. The formulas of TCTL are 
interpreted over the states of a model. The propositions and the clock variables 
of a TCTL formula ip are evaluated in states. 

Definition 5. (Semantics of TCTL) Let M be a model and let q G Sm be 

a state that is reachable in M. The state q satisfies the TCTL formula ip in 
M, denoted by q [=m */ 9 Ha/.O V for the empty clock environment 0. We 
define the semantics of the logic by means of a satisfaction relation M \= ip. This 
satisfaction relation is defined inductively as follows: 

- g 1= X - c iffv{x) ^ c 
-g|=x~y~c iff v{x) - v{y) ^ c 
-q^b iffbeL{q) 

- qh^^ iffq^f 

- q\^ (fiiV (P2 ijf q \= (fii or q \= (p2 

- q \= Lpi3Uip2 iff for some trajectory q G M with q (0, 0) = q, 
there exists a position (i,S) of q such that q {i,S) \=M,£+T{i,s) V2 and 

for allpositions {j,e) of q , if{j,e) -< {i,5) then q'{j,e) |=M,£+r(j\e) V(p2- 

- g 1= (fiilA(f2 iff for some trajectory q G M with q (0, 0) = q, 
there exists a position {i,5) of q such that q {i,S) \=M.£+T{i.S) ^2 and 

for all positions {j, e) of q , if {j, e) -< {i, S) then q {j, e) \=M.£+T(j,e) V (p2- 

a 

The basic TCTL operator in the above definition is the until operator which 
can be used to define the time interval in which the property should be true. As 
an example of the use of TCTL, consider the property "It is always true that ei 
may be followed by 62 within 10 time units" . This property can be expressed in 
TCTL as AG (ei ^ [true ^o.io]] 62). 

4 UPPAAL Model Checker 

UPPAAL [7] is a model checker for real-time systems developed in conjunction 
by Uppsala University, Sweden, and Aalborg University, Denmark. It extends 
the basic timed automata with features for concurrency, communication, data 
variables, and priority. The current version of the tool is 4.1.4 and it is freely 
available at |http: // www.uppaal.com UPPAAL uses a dense-time model to de- 
scribe systems, where each clock variable evaluates to a real number. An UP- 
PAAL model is a parallel composition of all of its timed automata. All automata 
start at its initial state (location) and run independently of each other unless 
synchronization with other automata is required. A transition is enabled when all 
enabling conditions are evaluated to true and all the synchronization statements 



are executed. If more than one transitions are enabled, one of them is chosen 
non-deterministicahy. In addition to binary synchronisation, UPPAAL supports 
also urgent and broadcast synchronisation. Synchronisation on urgent channels 
should occur as soon as both components are enabled. Note that in transitions 
with urgent channels, guards can not have clock constraints. A broadcast chan- 
nel allows a process (component) to synchronise with more than one component 
at the same time. Note that broadcast channels in UPPAAL are non-blocking 
in the sense that if a process has a transition with a!, where a is declared as a 
broadcast channel, then a! can be performed even when no a? action is enabled 
on any of the processes of the system. 

UPPAAL uses a client-server architecture which splits the tool into a graphi- 
cal user interface (client) and a model checking engine (server). The user interface 
consists of three main sections: system editor, simulator, and verifier. The edi- 
tor allows the user to model the system as a network of timed automata. The 
simulator gives the user the capability to interactively run the system to check 
if there are some trivial errors in the system design. The verifier allows the user 
to enter the properties to be verified in a restricted language of CTL. UPPAAL 
can verify safety, bounded liveness, and reachability properties. UPPAAL uses 
fragment of TCTL language and it does not support the direct verification of 
bounded response properties. 

4.1 The Protocol in UPPAAL 

The coordinator template is depicted in Figure [TJ Initially, the coordinator at- 
tempts to reserve a CPU time slot via sending a reservation request signal to 
the CPU resource manager (see Figure [3]) using the channel reserve [rsc_id] 
indexed with the resource to be allocated. If the CPU is busy in executing other 
tasks, the manager will add the coordinator process to the waiting queue. Other- 
wise, it will send immediately the process to the CPU for processing. When the 
manager receives a finished signal from the CPU indicates that the CPU has 
finished processing the current process and it is currently in an idle state, the 
manager will send the process at the front of the queue (if any) to the CPU for 
processing. The abstract model of the CPU (see FigureH]) has two locations idle 
and InUse which reflects the status of the CPU. When it receives a ready [pid] 
signal from process pid, it moves from idle to InUse, and then returns from 
InUse to idle after the determined execution time is completed. If the resource 
(CPU) is granted (rsc_grELnted ==true), the coordinator initiates the proto- 
col via broadcasting a start message to all the participants. The coordinator 
then waits to receive the votes of the participants. If V time units passed before 
receiving all the votes, the coordinator decides to abort and then terminate. 
Otherwise, it will move to location to2 at which it decides and broadcast the 
decision. A function result (part _ vote) returns the result of the transaction 
based on the values of the received votes. The coordinator broadcasts this result 
using the broadcast channel f in_result and the global variable outcome. The 
coordinator then moves to location m3 at which it waits to receive the comple- 
tion messages of the participants. If Dp time units passed before receiving all 



completion messages, it decides to abort and then terminate. The protocol ends 
successfully at location finished at which the coordinator updates its database 
server assuming that the clock x does not exceed the deadline D. 

The template of the participants is depicted in Figure [21 All the participants 
start their execution at location idle where they wait to receive a start signal 
from the coordinator. Once they receive that signal, each participant i will try to 
reserve time units via signalling the resource manager component. If the CPU 
is busy at that time, it will join the waiting queue until it gets executed. If the 
deadline V expired before sending their votes to the coordinator they decide to 
abort and then terminate. Each participant then moves to location r2 at which 
it waits to receive the decision of the coordinator. If it does not receive it within 
DEC time units, it decides to abort the transaction and terminate. Otherwise, 
it sets its comp variable to true and moves to location r4 where it updates its 
database server and terminates. 



x>=V 
decision ■- abort, 
outcome := abort, 
status ■- terminated 



o 

VExpired 



X >= Dp 
decision := abort, 
outcome := abort, 
status := terminated 



6 



Dp_Expired 

X D ' 

decision ■- abort, 
outcome := abort, 
status := terminated^X^ 

D_Expired 



X :=0, 

status:^ running 
reserve[rsc_id]! 



vote : voting 
coor_vote := vote 
rsc_granted[pid] true 
start ! 



decision:= abort, 
status := terminated 



isVoted true 



O 



outcome := result(part_vote) 

fin result! 



comp true && x < Dp 



-o 



o 



data_update ■- true, 
status := terminated 



Fig. 1. The coordinator template 
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o 



V_Expired 



decision := abort, 
status := terminated 



6 



DEC_Expired 



X >= D 
decision := abort, 
status := terminated 



x:=0, 

status := running 
start? 



reserve[rsc_id]! 



rsc_granted[pidj == true 
vote; voting 
part_vote := vote, 
isVoted := true 



-o 



X < DEC 
finresult? 
decision := outcome 
} 

comp := true 



X <D 

data_update := true, 
status := terminated 



o o 



D_Expired finished 
Fig. 2. The participant template 



5 Rabbit Model Checker 



Rabbit [9] is a model checking tool for real-time systems. The theoretical foun- 
dation of the tool is mainly based on timed automata extended with concepts for 



emptyO && !busy 
ready[pid]! 
reserve[pid]?^^ sc_granted[pid] := true 

lemptyO || busy == true 
add_to_queue(pid) 



o 




emptyO rscjranted[pid] := true 



Fig. 3. The resource manager template 



busy := false 
finished! 
X == exe time 



Idle 

ready[pid]? 
x:=0, busy := true 



InUse 



X <= exe_time 

Fig. 4. The abstract CPU template 



modular modeling. This tool has been developed by Dirk Beyer and his research 
group at the University of Passau, Germany. The current version of the tool is 
2.1. The tool is freely available at http://www.sosy-lab.org/ dbeyer/ Rabbit, The 
tool deals with timed systems using BDD data structure and uses some heuristic 
techniques to compute good variable orderings of the model and an estimate of 
the BDD size. Rabbit has been designed to be able to handle large systems in 
an efficient way and it supports the following features: 

— Modular Modeling. Rabbit uses modular extension of timed automata called 
Cottbus Timed Automata (CTA). That is, the automata are encapsulated by 
modules. Each module in the model has an explicit interface that contains 
variables and synchronisation labels that are used to allow the module to 
communicate with other modules. In Rabbit we can declare models in a 
hierarchical structure in the sense that modules in the model can contain 
other modules. 

— Reachability Analysis. Rabbit uses an efficient approach for analysing reach- 
ability properties of timed automata. It uses a symbolic approach based on 
BDD data structure as a representation of the explored state space. 

— Refinement Checking. Rabbit verifies large systems via replacing their con- 
crete models with more abstract ones. It uses simulation-based techniques 
to show that both models, the concrete and the abstract one, have the same 
behaviour. 

We now give an informal description of the formalism of Cottbus Timed 
Automata (CTA), which is used in the modeling language of Rabbit. [TT| . 

A CTA system consists of a set of modules that can be defined in a hierar- 
chical way. One of them (the one at the top of the hierarchy) is used to model 
the whole system. The other modules are used as templates. 

Each module in the system model should have the following components: 

— An identifier. Identifiers are used to name the modules within the system 
description. Using identifiers we can create several instances of the modules 
associated with these identifiers. 



— An Interface. The interface of a module contains the declarations of the 
variables that are used in that module. In a CTA module, we can declare 
clock variables, discrete variables, and synchronisation labels. 

• Synchronisation labels. Sometimes called signals which are used to syn- 
chronise timed automata that exist in different modules in the system. 
The concept of synchronisation labels in modules is very similar to the 
concept of events in CSP. 

• Variables. Rabbit allows us to declare both continuous (clock) variables 
and discrete variables. The values of these variables can be updated using 
assignment statements in the transition rules of the automaton. 

— A timed automaton. Each module contains a timed automaton. The automa- 
ton consists of a finite set of states, a finite set of transitions, and a set of 
synchronisation labels. In CTA language, a process transition is declared as 
a transition rule which starts with the keyword TRANS, while the locations 
of the automaton are declared using the keyword STATE. 

— Initial condition. This is a formula over the module variables and the states 
of the module's automaton, which specifies the initial state of the module. 

— Instances. In CTA model, a module can contain instances of of the other de- 
fined modules in the model. This is useful when we model systems containing 
subsystems, and that these subsystems occur several times in a system. 

The textual description of the protocol in the Rabbit input language is given 
in Appendix [Xl 

6 RED Model Checker 

RED [5S] stands for (Region-Encoding Diagrams) is a TCTL model checker for 
real-time systems. This model checker has been designed and developed by Earn 
Wang and colleagues at the National Tawian University. The current version of 
the tool is 5.0. The RED tool is available for free at|http://cc.ee.ntu.edu.tw/ farn 
An interesting feature of the RED model checker is that it is totally based on 
symbolic technology with BDD-like diagrams. RED now supports varieties of 
data-structures, which can be described as follows. 

— Timed automata with CRD (Clock-Restriction Diagram) technology, 

— linear hybrid automata with HRD (Hybrid- Restriction Diagram) technology, 

— MDD-based diagrams which stands for multi-value decision diagrams and 
is very much like BDD except that variables are now decimal and arcs are 
labeled with value intervals. 

In RED, systems are described as parametrized communicating timed au- 
tomata (CTA), where processes can be model processes, specification processes, 
or environment processes. In a system with n processes, the user invokes the 
RED model checker via telling it which processes are for the model, and which 
for the specification. The remaining processes will be for the environment. Since 
the automata in RED are parametrised automata (i.e. we can pass parameters 



to them) then we can declare many process automata with the same automa- 
ton template and identify each process automaton with a process index. RED 
supports both forward and backward analyses, deadlock detection, and counter- 
example generation. In RED, users can declare global and local variables of type 
boolean, discrete, clock-restriction variable, and hybrid-restriction variable. The 
tool also supports several optimisation (reduction) techniques that help to ma- 
nipulate the state space of the system under consideration in an efficient way such 
as symmetry reduction, inactive variable elimination, performance enhancement 
techniques for time inevitability evaluation. RED differs from the two tools dis- 
cussed above in that it uses an extended version of TCTL with. It also supports 
strong and weak fairness assumptions of CTA. 

The textual description of the protocol in the language of RED is given in 
Appendix |B1 

7 Correctness Conditions 

The first formula of interest is global atomicity (i.e. all processes must agree 
on the final decision: all must abort or all must commit.) We might first specify 
atomicity as AFAG iAi=ij (^-decision — j. decision)). Intuitively, the formula 
states that for all possible paths there will be a state where all processes globally 
agree on their final decision. Unfortunately, the protocol can not be expected 
to satisfy this since processes might decide to commit and then change their 
decision to abort if the deadlines Dp or D expired during the execution of the 
protocol: suppose that all the participants have voted to commit the transaction 
and they were able to deliver their votes before the expiry of the deadline V. 
Suppose further that the coordinator broadcasted a commit message before the 
expiry of the DEC deadline but it failed to receive the completion messages within 
the deadline Dp. In this case, the coordinator will change the global decision from 
commit to abort and then broadcast an abort message. So there are situations 
in the protocol where processes may change their decisions. We therefore write 
the following weaker specification of atomicity: 

Specification 1: The global atomicity is always guaranteed. 

AG (/y ^(i. decision = a&ort A j. decision = commit)) 

Note that the variable decision can take one of the following values {undefined, 
abort, commit}. Initially, we set the decision of each participant to the undefined 
value. Note that by verifying atomicity property we verify implicitly consistency 
property since ensuring atomicity guarantees data consistency on all distributed 
database systems. 

The second property of interest is validity (i.e. if process i votes 'no' then 
'no' is the only possible decision value, also if all processes vote 'yes' then 'yes' 
is the only decision value). We might specify validity as follows: 



Specification 2(a): If one process voted 'no' then all processes will eventually 
abort. 

AG ( \J (i.vote = no) => AF (outcome = abort)) 

i=l..n 

Specification 2(b): If all processes voted 'yes' then all processes will eventually 
commit. 

AG ( (i.vote = yes) AF (outcome = commit)) 

i—l..n 

Recall that the goal of the protocol is to preserve data consistency as well as 
to satisfy all designated intermediate deadlines Dp, DEC, and V. If any of these 
deadlines expired during the execution of the transaction, it is immediately killed 
(i.e. all processes will decide to abort). Note that the execution of the transaction 
may be delayed due to queuing delay or due to a communication delay which 
might cause the protocol to miss its deadlines. The following three specifications 
verify whether the protocol can satisfy these deadlines. 

First, the participants should respond in a bounded time delay to the coor- 
dinator commit request message via sending their votes no more than V time 
units after the coordinator sends the request. 

Specification 3: If there are no faults and the coordinator C sent a commit 
request message at time x\ , then it is guaranteed to receive all participants ' votes 
by xi + V on the the coordinator's clock. 

AG ((C . request_sent = true A t = xi) => 

AF (Ai=i „ (C. vote_received[i] = true) A t < xi + V)) 

Second, the coordinator should broadcast the decision no more than DEC time 
units after receiving the participants votes. 

Specification ^: If there are no faults and the coordinator received the votes 
at time X2, then all the participants can receive the decision by xn + DEC on 
any participant Pi 's clock. 

AG ((/\.^;^ ^(C.vote_received[i] = true) A t = X2)) 

AF (A,=i „(i.decision_received= true) A t < X2 + DEC)) 

Next, the coordinator should be able to receive all acknowledgements within 

Dp time units after it sent the decision. 

Specification 5: If there are no faults and the coordinator sent the decision 
at time xs, then it can receive all acknowledgements within X3 + Dp on the 
coordinator's clock. 

AG ((C.decision_sent = true A t = 2:3) 

AF (Ai=i..„ (C.ack[i] = true) A t < ^3 + Dp)) 

Finally, all processes should terminate within D time units after the coordinator 
initiates the protocol. Note that we consider the protocol failed to achieve its 
goal if it can not completed within D time units after it started. 



Specification 6: The protocol must always terminate within D time units after 
it started. 



8 Specifying The Protocol Properties in UPPAAL, 
Rabbit, and RED 

In this section, we discuss how we verify the properties of the protocol in the 
specification language of each tool. UPPAAL uses fragment of TCTL logic, RED 
uses complete TCTL logic, while on other hand, TCTL is not available in Rabbit 
and it uses techniques based on reachability analysis to verify systems properties. 
In order to simplify the discussion of the specifications, we consider a setting 
with only one coordinator and one participant. However, in our verification of 
the protocol (see section [TU]) , we consider also settings with large numbers of 
participants. 

In UPPAAL, we can capture specification I as follows. 

A[] not (coor . decision == commit and part . decision == abort) 

The formula states that it is always not (never) the case that one process will 
decide to commit and one other process decides to abort (i.e. all processes must 
agree on the final decision). 

Since Rabbit does not support the TCTL language, it alternatively provides 
an analysis command language to write a simple segment of code for verifying 
properties based on reachability analysis. Using this language, we declare a set 
of variables that are used to represent a set of states, called regions, followed 
by a set of iterative command statements. We then check whether the model 
can reach a region where the formula can be violated. The code below expresses 
specification I in Rabbit's analysis language. 

REACHABILITY CHECK T2PC 
{ 

1 VAR initial, error, reached : REGION; 

2 COMMANDS 

3 initial := INITIALREGIDN; 

4 error := ( (coor . decision == 1) AND (part . decision ==2)) OR 

5 ( (coor . decision == 2) AND (part . decision ==1)); 

6 reached := REACH FROM initial FORWARD; 

7 IF (EMPTY (error INTERSECT reached) ){ 

8 PRINT "Specification 1 satisfied.";} 

9 ELSE { PRINT " Specification 1 violated.";} 



The first line declares three regions. Region initial represents the set of initial 
states from the Rabbit's modules (see appendix VK\ . Lines 4 and 5 characterize 




i—l..n 



} 



the set of states that violate specification 1 of the protocol: some process decided 
to abort while some other process decided to commit. Line 6 assigns to reached 
the set of states reachable from the initial state. The specification is satisfied 
if the intersection between the reached region and the error region is empty. 
Note that we verify the protocol model using the FORWARD reachability analysis 
option. One can verify the model also using backward reachability via replacing 
the option FORWARD in fine 6 with the BACKWARD option. 
In RED we can express specification 1 as follows. 

forall always not (decision [1] == 1 && decision [2] == 2) 

The above RED formula says that for all possible paths of the protocol, there is 

no path where process 1 (the coordinator process) decides to abort (decision [1] == 1) 

while process 2 (the participant process) decides to commit (decision [2] == 2). 

Specification 2 can be captured in UPPAAL's specification language as fol- 
lows. 



A [] (coor_vote == abort or part_vote == abort imply outcome == abort) or 

(coor_vote == commit and part_vote == commit imply outcome == commit) 

Intuitively, the above UPPAAL formula says that if one of the processes voted 
to abort the transaction then the global outcome of the protocol will be abort. 
While on the other hand, if all processes voted to commit then the final outcome 
will be commit. 

In Rabbit we can verify specification 2 as follows. 

REACHABILITY CHECK T2PC 

1 VAR initial, error, reached : REGION; 

2 COMMANDS 

3 initial := INITIALREGIDN; 

4 error := ( ((part. vote == 1) OR (coor.vote == 1)) AND (outcome == 2)) OR 

5 ( (part. vote == 2) AMD (coor.vote ==2) AMD (outcome == 1)); 

6 reached := REACH FROM initial FORWARD; 

7 IF (EMPTY(error INTERSECT reached)) 

8 {PRINT "Specification 2 satisfied.";} 

9 ELSE { PRINT " Specification 2 violated.";} } 

Lines 4 and 5 in the above Rabbit code characterize the set of states that violate 
specification 2: one process voted to abort the transaction while the coordinator 
decided to commit it, or all processes voted to commit the transaction while 
the coordinator decided to abort it. Again the specification is satisfied if the 
intersection between the reached region and the error region is empty. 
While in RED we can specify property 2 as follows. 



forall always ((vote[l] ==1 II vote [2] ==1 implies outcome ==1) OR 
(vote[l] ==2 && vote [2] ==2 implies outcome ==2)) 



Note that the local variable vote can take one of the following values (unde- 
fined), 1 (abort), and 2 (commit). 

Next, since UPPAAL and Rabbit lack the expressiveness to capture directly 
bounded response properties, we therefore verify specifications (3-5) via reduc- 
ing them into reachability properties. We can verify specification 3 in the tools 
UPPAAL, Rabbit, and RED respectively as follows. 

A [] not (coor .V_Expired) 

The formula states that there is no path where process coor can reach location 
V_Expired. If the property does not satisfy then there exists a counterexample 
where the deadline V expires before the coordinator can receive the votes of the 
participants. 

In Rabbit we express specification 3 as follows. 

REACHABILITY CHECK T2PC 

■c 

1 VAR initial, error, reached : REGION; 

2 COMMANDS 

3 initial := INITIALREGION; 

4 error := STATE (Coor. coor) = waitVotes AND coor.x > V; 

5 reached := REACH FROM initial FORWARD; 

6 IF (EMPTY (error INTERSECT reached) ){ 

7 PRINT "Specification 3 satisfied.";} 

8 ELSE { PRINT " Specification 3 violated.";} 
} 

The declaration of the region error in the above Rabbit code states that the 
clock of coordinator exceeds the deadline V while the coordinator is still waiting 
for the participant's vote at location waitVotes. 

Since RED uses complete TCTL language, we can then express specification 
3 straightforwardly as follows. 

forall always (waitVotes [1] => forall eventually {<= V} sendDecision [1] ) 

Intuitively, the above RED formula says that the coordinator process (process 
1 in the RED model) can always move from location waitVotes to location 
sendDecision within V time units. According to the RED model (see appendix 
[B|) . this means that the coordinator can always receive the participants' votes 
within V time units after it sends the start message. 

Next we can express specification 4 in UPPAAL as follows. 

A[] not (part . DEC_Expired) 

We can capture specification 4 in Rabbit language using a code similar to the 
code that we use to express specification 3 while modifying the assignment of 
the error region as follows. 



error := STATE (Part .part) = waitDEC AND part.x > DEC; 



In RED we can express the specification as follows. 



forall always (part_wait [2] => forall eventually {<= DEC} sendCompMsg[2] ) 

Specification 5 can be expressed in UPPAAL as follows. 

A[] not (coor .Dp_Expired) 

To verify specification 5 in Rabbit we modify the assignment of the error region 
as follows. 

error := STATE (Coor . coor) = waitCompMsg AMD coor.x > Dp; 
In RED we specify the property as follows. 

forall always (waitCompMsg [1] => forall eventually {<= Dp} coor_f inal [2] ) 

Finally, specification 6 can be verified in UPPAAL as follows. 

AO (coor.x == D imply coor. status == terminated and 
part.x == D imply part. status == terminated) 

In Rabbit we verify specification 6 as follows. 

REACHABILITY CHECK T2PC 
{ 

1 VAR initial, error, reached : REGION; 

2 COMMANDS 

3 initial := INITIALREGION; 

4 error := ((coor.x >= D) AND (coor. status == 0)) OR 

5 ((part.x >= D) AND (part. status == 0)); 

6 reached := REACH FROM initial FORWARD; 

7 IF (EMPTY(error INTERSECT reached)) 

8 {PRINT "Specification 6 satisfied.";} 

9 ELSE { PRINT " Specification 6 violated.";} 
} 

Lines 4 and 5 in the above Rabbit code characterize the set of states that violate 
specification 6: the coordinator clock x exceeds the deadline D while the coordi- 
nator is still running, or the participant clock x exceeds the deadline while the 
participant process is still running. 

In RED we can specify the property as follows. 

forall eventually (x[l] == D implies status [1] == 1 AND 
x[2] == D implies status [2] == 1) 

Note that the local variable status in the above RED's formula can take 
one of the following values (means the process is running), and 1 (means the 
process has been terminated). 



9 Verification Results 



We verify first a strong formula of atomicity AG{/\^_^j (i. decision = j. decision)) 
in which all processes can reach to the same decision at the same time. Recall 
that initially each process sets its decision to the undefined value which will be 
changed during the execution of the protocol to cither commit or abort based on 
the values of the votes. As we expect the formula does not satisfy since processes 
may not be able to receive the decision of the coordinator at the same time due 
to communication delay or queuing delay. We therefore consider a weaker def- 
inition of atomicity AFAG {f\i=£j (i-decision = j. decision)). We also found 
this specification fails since as we discussed before processes might change their 
decision from commit to abort if the deadlines Dp or D expire during the exe- 
cution of the protocol. We finally verify atomicity as expressed in specification 
1 and found the specification holds. Under this weak definition of atomicity the 
consistency of the databases might be temporarily broken. For example we might 
have situations in the protocol where process i commits at real-time 10, process 
j commits at real-time 15, and process k commits at real-time 20. The protocol 
allows such situations to occur, in particular when some processes get delayed 
while waiting to get executed. However, when the protocol does terminate, the 
consistency of the distributed databases is preserved. 

The next question of interest is then whether validity specifications always 
hold , as claimed. The answer obtained by model checking is that Specification 
2(a) holds while surprisingly Specification 2(h) fails where the counter-example 
discovered is the following: 

Example 1: Suppose that all processes have voted to commit the transac- 
tion ^(i.vote = yes)) and that the coordinator has received the votes 
within the deadline V. Suppose further that the coordinator broadcasted the 
global decision before the expiry of the deadline DEC but it failed to receive 
the completion messages within the deadline Dp. According to the rules of the 
protocol, the coordinator will decide to abort the transaction due to the expiry 
of Dp and set the global variable outcome to the abort value. Hence we have a 
situation where although all processes voted to commit, the coordinator decided 
to abort the transaction, and therefore Specification 2(b) fails. 

The correctness of specifications (3-6) depends mainly upon the satisfaction 
of the following three conditions: (1) absence of node or link failures since failures 
if happen might cause some processes to miss their deadlines. (2) the ability 
of the operating environment to deliver messages on-time and that messages 
loss is not possible. (3) fair scheduling policy: each process i is guaranteed to 
execute at least ti time units: the time needed to receive a decision message from 
the coordinator, perform the commit or abort action, and send a completion 
message to the coordinator. In our modeling of the protocol we assume that all 
resource managers use non-preemptive scheduling policy in the sense that when a 
process starts executing, it continues executing until it completes its determined 
execution time. Since we made these three assumptions about the environment 
of the protocol, we therefore found specifications (3-6) hold. 



10 Model Checking Performance 



In this section, we present the model checking runtimes obtained in testing the 
tools, with version 4.1.4 for UPPAAL, 2.1 for Rabbit, and 5.0 for RED. All exper- 
iments are conducted on a PC with Redhat Linux 7.3 with Intel (R) core(TM)2 
Quad CPU 2.6 GHz and 512 MB memory. The specifications of the protocol 
were checked with backward and forward analysis in Rabbit and RED, and us- 
ing the on the fly approach for UPPAAL. In the forward analysis method the 
model checker attempts to construct a characterization of all states that can 
be reached from a set of initial states / with respect to the declared behaviour 
structure M . In the backward reachability analysis the model checker attempts 
to construct a characterization of all states that can reach specific goal states 
(unsafe states) with respect to the declared behaviour structure. While in on- 
the-fly approach, the state space of the system is generated dynamically and only 
the minimal amount of information is stored in memory. In the tables below we 
show the CPU time used by the system on behalf of the calling process (system 
time). An entry of "x" indicates that the model checker ran out of memory on 
that specification. Rabbit and RED ask for only one input file which describes 
both the components of the system and the formula to be verified. While on the 
other hand, UPPAAL asks for two input files, one for the system and another 
one for the logical formula. As shown in section [7] some properties of the protocol 
require us to use a full TCTL language and verify formulas with nested tem- 
poral modalities which are not allowed in both UPPAAL and Rabbit. We have 
therefore weakened the properties of the protocol until UPPAAL and Rabbit 
can handle them, as shown in section |8l 



Backward analysis 




Specification 


Number of processes 


Model Checker 


1 


2(a) 


2(b) 


3 


4 


5 


6 


6 


Rabbit 


1.22 


1.25 


1.66 


1.21 


1.37 


1.5 


1.68 


6 


RED 


10.88 


4.13 


8.42 


12.9 


11.26 


9.57 


6.19 


9 


Rabbit 


X 


x 


X 


X 


X 


X 


X 


9 


RED 


554 


249 


734 


981 


859 


732 


1584 


12 


Rabbit 


X 


x 


X 


X 


X 


X 


X 


12 


RED 


2667 


979 


5524 


6135 


6283 


4339 


8540 



Table 1. Model Checking Runtimes (seconds) for Rabbit and RED With Backward 
Analysis 



We scaled the model of the protocol until the tools could not verify the pro- 
tocol properties, due to state space problem. The complexity of the analysis 
depends mainly on the number of clocks and states in the model. In Table 1 
we give the runtimes obtainted in checking the protocol using Rabbit backward 
reachability analysis and RED backward TCTL model-checking. RED could ver- 



Forward analysis 




Specification 


Number of processes 


Model Checker 


1 


2(a) 


2(b) 
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4 
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6 


6 


Rabbit 


160 


162 


164 


160 


161 


163 


172 


6 


RED 


2.58 


1.69 


2.47 


1.19 


1.36 


1.52 


1.87 


9 


Rabbit 


X 


X 


X 


X 


X 


X 


X 


9 


RED 


69.7 


46.3 


59.3 


26.9 


29.5 


31 


40.6 


12 


Rabbit 


X 


X 


X 


X 


X 


X 


X 


12 


RED 


3088 


1705 


1989 


884 


939 


943 


1322 



Table 2. Model Checking Runtimes (seconds) for Rabbit and RED With Forward 
Analysis 



ify successfully the protocol up to 12 processes with 8 clocks, while Rabbit could 
verify only the simplest cases of the protocol. Although that Rabbit uses a 
discrete-time semantics of timed automata which is considered easier and sim- 
pler than the dense-time semantics adopted by RED and UPPAAL, it failed to 
analyse instances of the protocol with large number of processes. In Table 2 we 
report the runtimes obtained in testing the tools Rabbit and RED using forward 
reachability analysis. Optimizations used in RED make it more scalable than 
Rabbit by several order of magnitude. It should be noted that the latest avail- 
able version of Rabbit has been released in 2003 which has not been updated 
since that date. While on the other hand, many optimisations have been added 
to the tool RED in the last few years, which give it the opportunity to perform 
much better than Rabbit. 

In Table 3 we give the model-checking runtimes of the protocol using UP- 
PAAL's on the-fly approach. UPPAAL could verify successfully the protocol 
up to 9 processes with 6 clocks. As wc can see, on the whole, the CRD-based 
tool RED could analysed the protocol more efficient than the DBM-based tool 
UPPAAL and the BDD-based tool Rabbit. 



On The Fly Approach 




Specification 


Number of processes 
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2(a) 


2(b) 
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0.01 


0.008 


0.007 


0.001 


0.002 


0.003 


0.045 


9 


4.4 


0.01 


0.06 


0.05 


0.013 


0.084 


0.01 


12 


X 


0.9 


0.01 


O.lKi 


0.5:', 


X 


0.057 



Table 3. Model Checking Runtimes (seconds) for UPPAAL With On the Fly Approach 



In general this case study increased our insight into the state of the art in 
dense-time model checking, and our understanding of the algorithms and data 



structures that are used in the implementation of the current dense-time model 
checking tools. It shows also the capabilities and the limitations of the model 
checkers UPPAAL, Rabbit, and RED. 

11 Related Work 

Some work has already been done on the verification of commitment protocols 
using formal techniques. In particular, the basic 2PC protocol has frequently 
been the focus of studies of verification of distributed computing |20I6I15|2T| . 
but it is just one of several variants discussed in the literature. One of the 
interesting variants of the protocol is the T2PC protocol that has complex timing 
constraints. In this work we have shown how the protocol can be analyzed with 
three various tools: UPPAAL, Rabbit, and RED. To the best of our knowledge 
the T2PC protocol has not been model checked before. 

The literature of timed automata theory is a rich literature since it was intro- 
duced by Alur and Dill in 1990. Alur and Madhusudan [S] present a full survey of 
known results for decidability problems in timed automata theory. Tripakis [2 3) 
gives algorithms and techniques to verify timed systems using TCTL logic and 
Timed Buchi Automata, which have implemented in KRONOS model checking 
tool. One of the disadvantages of KRONOS is that its input language supports 
a very restricted data types that allow only the declaration of clock variables. 
For this reason we have not included KRONOS in our comparative study. 

In the last few years, BDD-like data structures have been used in the verifi- 
cation of timed systems. The model checkers Rabbit has been developed based 
on BDD technology. Emprical results given in [24] and [9] have shown that RED 
and Rabbit outperformed UPPAAL in some particular examples such as Fisher 
mutual exclusion and FDDI Token Ring protocol. 

Beyer and Noack [TU] compared the three tools via considering the verification 
of a set of simple benchmarks such as the Fischer mutual exclusion protocol, and 
CSMA/CD. Experiments show that the tools RED and Rabbit perform better 
than UPPAAL when considering a large number of processes. However, heuristics 
used in Rabbit make the tool more scalable than RED. 

Wang [23] show that CRDs outperform DBMs when verifying specifications 
that contain large number of clocks. However, he pointed out that CRDs con- 
sume much space (memory) in handling intermediate data structures, and there- 
fore require intensive use of garbage collection. Note that the emprical results 
presented in the above discussed works were reported using an old version of 
UPPAAL (v3.2.4), which lack many of the optimisations that are used in the 
current version of the tool (v4.1.4). 

RED is able to verify properties that are not expressible in UPPAAL and 
Rabbit and it supports full TCTL language with fairness assumptions. RED also 
allows verifying formulas that contain nested temporal modalities (i.e. AF AG{(p)). 
On the other hand, UPPAAL's specification language supports fragment of 
TCTL and nested temporal formulas are not allowed, while Rabbit language 
is restricted to reachability formulas. Unlike UPPAAL, RED and Rabbit pro- 



vide no graphical interface or simulation facilities. One advantage of Rabbit over 
the other tools is that it supports modular modelling that allows us to represent 
the system components in a hierarchy way. This facilitates the modelling of com- 
plex timed systems. However, UPPAAL has richer expressiveness in modeling 
real-time systems than Rabbit and RED. (i.e. The support of data variables in 
Rabbit and RED is more limited than it is in UPPAAL.) 

12 Conclusions 

Wc have modeled and verified the real-time version of the two phase commit 
protocol in the model checkers UPPAAL, Rabbit, and RED. RED outperformed 
UPPAAL and Rabbit in terms of performance and scalability and allowed us 
to verify the protocol for large number of processes. Our analysis showed that 
the central property of the protocol, the data consistency property, might be 
temporarily broken during the execution of the protocol, however, when the 
protocol terminated the consistency is preserved. The three model checkers vary 
in how easy, or difficult, it is to formalise the protocol in the language of each 
model checker, and then to verify its correctness properties. The input language 
of UPPAAL, Rabbit, and RED are substantially different, and they arc suited 
for different classes of examples. We intend to pursue this investigation by con- 
sidering more complex real-time commit protocols and verifying more complex 
real-timed properties. 
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A The Textual Description of The Protocol in Rabbit 

MODULE Coordinator 



LOCAL 

X : CLOCK; vote : DISCRETE (3) ; update : DISCRETE; 
decision : DISCRETE (3) ; status : DISCRETE; 
INPUT 

//the deadline of the transaction. 
// the deadline for receiving participants' votes. 
// the deadline for receiving participants' completion messages. 



D : CONST 
V : CONST 
Dp: CONST 
commit 
abort 
comp 
OUTPUT 

reserve 

start 



SYNC; // to commit the transaction. 

SYNC; // to abort the transaction. 

SYNC; // to receive the participant's completion message 

SYNC; // to reserve a CPU time slot. 
SYNC; // to start the T2PC protocol. 



MULTREST 

outcome : DISCRETE; 

resource_granted : DISCRETE; 

dec_sent : DISCRETE; 
// Set initial state of automaton aind clock values. 
INITIAL 

STATE (Coor) = init AND x = AND status =0; 
AUTOMATON Coor 
{ 

STATE init{ TRANS-C SYNC ! reserve; GOTO begin;} 

TRANS {GUARD x >= V; GOTO fail;} } 
STATE begin{ TRANS{ GUARD resource_granted = 1; 

SYNC ! start; DO vote' =1; GOTO waitVotes;} 
TRANS {GUARD resource_granted = 1; 

SYNC ! start; DO vote' =2; GOTO waitVotes;}} 
STATE waitVotes {TRANS{ SYNC ?abort; DO decision' =1 AND dec_sent' =1 

AND outcome' =1; GOTO waitCompMsg; } 
TRANS {GUARD vote =2; SYNC ?commit; DO decision' =2 AND 
dec_sent' =1 AND outcome' =2; 
GOTO waitCompMsg;} 
TRANS {GUARD vote =1; SYNC ?commit; DO decision' =1 AND 
dec_sent' =1 AND outcome' =1; 
GOTO waitCompMsg;} 
TRANS {GUARD x >= V; GOTO fail;}} 
STATE waitCompMsg{ TRANS {SYNC ?comp; GOTO finish; } 
TRANS {GUARD x >= Dp; GOTO fail;}} 



STATE finish{ TRANS 



STATE fail{ 



TRANS 
TRANS 



{GUARD X <=D; DO update' = 1 AND status' =1; 

GOTO exception;} 
{GUARD x> D; GOTO exception;} } 
{DO decision' = 1 AND outcome' =1 



AND status' =1; GOTO exception;}} 

STATE exception {} 

} 
} 

// The following module represents the template of the participant. 

MODULE Participant 

i 

LOCAL 

X : CLOCK; vote : DISCRETE (3); 

decision : DISCRETE(3) ; status : DISCRETE (2) ; update : DISCRETE; 
INPUT 

D : CONST; V : CONST ; DEC : CONST; start : SYNC; 
OUTPUT 

reserve : SYNC; commit : SYNC; abort : SYNC; comp : SYNC; 
MULTREST 

outcome : DISCRETE; 

resource_granted : DISCRETE; 

dec_sent : DISCRETE; 
// Set initial state of automaton and clock values. 
INITIAL 

STATE(Part) = init AND x = AND status =0; 
AUTOMATON Part 

{ 

STATE init{ TRANS {SYNC? start; GOTO reserveTimeSlot ; } 

TRANS {GUARD x >= V; GOTO fail;} } 
STATE reserveTimeSlot{ TRANS {SYNC ! reserve; GOTO sendVote;} 

TRANS {GUARD x >= V; GOTO fail;} } 
STATE sendVote{ TRANS {GUARD resource_granted = 1 AND x <V; 

SYNC ! abort; DO vote' = 1; GOTO waitDec;} 
TRANS {GUARD resource_granted = 1 AND x <V; 

SYNC ! commit; DO vote' = 2; GOTO waitDec;} 
TRANS {GUARD x >= V; GOTO fail;}} 

STATE waitDec{ TRANS {GUARD x >= DEC; GOTO fail;} 

TRANS {GUARD x < DEC AND dec_sent=l; DO decision' = outcome 
GOTO sendCompMsg;} } 
STATE sendCompMsg{ TRANS {SYNC ! comp; GOTO finish;} } 

STATE fail{ TRANS {DO decision' = 1 AND status' =1; GOTO exception; 

STATE finish{ TRANS {GUARD x <D; DO update' = 1 AND status' =1; 

GOTO exception;} 
TRANS {GUARD x>= D; GOTO exception;} } 

STATE exception {} 

} 
} 

// The following module represents an abstract model of the CPU. 



MODULE resource 
{ 

LOCAL 

X : CLOCK; 
INPUT 

ready : SYNC; 

exe_time : CONST; 
OUTPUT 

finished : SYNC; 
MULTREST 

busy : DISCRETE; // means the CPU is free, and 1 means it is busy. 
INITIAL 

STATE (CPU) = Idle AND x =0 AND busy =0; 
AUTOMATON CPU 
{ 

STATE Idle{ TRANS {SYNC ? ready; DO x' =0 AND 

busy' =1; GOTO InUse;} } 
STATE InUse{ INV x<= exe_time; 

TRANS {GUARD x = exe_time; SYNC ! finished; 

DO busy' = 0; GOTO Idle;} } 

} 
} 

// The template of the CPU manager. 

MODULE ResouceMcinager 

{ 

LOCAL 

wait : DISCRETE; 
INPUT 

reserve : SYNC; finished : SYNC; 
OUTPUT 

ready : SYNC; 
MULTREST 

busy : DISCRETE; // means the CPU is free, and 1 means it is busy. 

resource_granted : DISCRETE; 
INITIAL 

STATE (Manager) = Idle; 
AUTOMATON Manager 
{ 

STATE Idle { TRANS {SYNC ? reserve; GOTO Ml;} 

TRANS {SYNC ? finished; GOTO M2;} } 
STATE Ml{ TRANS {GUARD busy =0; 

SYNC ! ready; DO resource_granted' = 1; GOTO Idle;} 
TRANS {GUARD busy = 1; 

DO wait' =1; GOTO Idle;} } 
STATE M2{ TRANS {GUARD wait =1; SYNC ! ready; DO wait' =0 



AMD resource_granted' = 1; GOTO Idle;} 
TRAMS {GUARD wait = 0; GOTO Idle;}} 

} 
} 

We pick some statements in the Rabbit model in order to explain how to declare 
the model behaviour structure with Rabbit. The declaration is a sequence of 
STATE declarations. A typical STATE declaration can be found from the state- 
ments (SI) to (S3). The statements declare a state whose name is InUse and 
whose invariance condition is "x<= exe_time". Inside the transition TRANS we 
have a synchroniser finished, a triggering condition "x == exe_time" , and two 
actions "DO busy ' = ; " and "GOTO Idle ; " . Another statement that we believe 
it needs to be explained is the declaration statement decision: DISCRETE (3). 
The parameter in the statement tells Rabbit how many values we want to store 
in the variable decision. The statement indicates that the decision variable 
can take one of the following values {0,1,2}. This gives Rabbit the opportu- 
nity to spend the correct number of bits in the BDD representation. Note that 
synchronization between automata is done via synchronization labels and the 
semantic is as in CSP, i.e., one automaton can take a transition with label S, if 
all other automata also take a transition with S. 



B The Textual Description of The Protocol in RED 

#define D 80 

#define D_p 52 
#define DEC 40 
#define V 15 
#define exe_time 52 
process count = 6; 
/* One local clock. */ 
local clock x; 

/* A set of synchronizers . */ 

global synchronizer start, reserve 1, reserve2, yes, no, commit, abort, 

comp, readyl, ready2, finishedl, finished2; 
local discrete vote: 1..2; 
local discrete decision: 0..2; 
local discrete update: 0..1; 
local discrete status: 0..1; 
global discrete busyl: 0..1; 
global discrete busy2: 0..1; 
global discrete outcome: 1..2; 
global discrete resource_grantedl : 0..1; 
global discrete resource_granted2: 0..1; 
global discrete waitl: 0..1; 
global discrete wait2: 0..1; 



/* 7 modes for the coordinator. */ 
mode coor_idle (true) 
{ 

when ! reservel (true) may goto coor_begin; 

} 

mode coor_begin (true) 

{ 

when ! start (resource_graiitedl ==1) may x= 0; vote =1; goto wait_votes; 
when ! start (resource_graiitedl ==1) may x= 0; vote =2; goto wait_votes; 

} 

mode wait_votes (x<=D) 
{ 

when ?yes (vote ==2 && x < V) may decision =2; outcome =2; goto sendDecision; 
when ?yes (vote ==1 && x < V) may decision =1; outcome =1; goto sendDecision; 
when ?no (x < V) may decision = 1; outcome =1; goto sendDecision; 
when (x >= V) may goto coor_fail; 

} 

mode sendDecision (x <=D) 
{ 

when [commit (decision == 2) may goto waitCompMsg; 
when ! abort (decision == 1) may goto waitCompMsg; 

} 

mode waitCompMsg (x<=D) 
{ 

when ?comp (x < D_p) may goto coor_final; 
when (x>D_p) may goto coor_fail; 

} 

mode coor_final (true) 
{ 

when (x < D) may update =1; status =1; 
when (x> D) may goto coor_fail; 

} 

mode coor_fail (true) 
{ 

when (true) may decision =1; outcome =1; status =1; 

} 

/* The behaviour of the participant can be described as follows.*/ 
mode part_idle (true) 
{ 

when ?start (true) may x = 0; goto part_reserve; 

} 

mode part _reserve (true) 
{ 

when ! reserve2 (true) may goto part_start; 



> 

mode part_start (x < D) 
i 

when lyes (resource_grEinted2 ==1 && x < V) may vote =2; goto part_wait; 
when !no (resource_granted2 ==1 && x < V) may vote =1; goto part_wait; 
when (x >= V) may goto part _f ail; 

> 

mode part_wait (true) 
i 

when ?abort (x < DEC) may decision =1; goto sendCompMsg; 
when ?commit (x < DEC) may decision =2; goto sendCompMsg; 
when (x>= DEC) may goto part _f ail; 

} 

mode sendCompMsg (true) 
i 

when !comp(true) may goto part_final; 

> 

mode part_final (true) 

{ 

when (x < D) may update =1; status =1; 
when (x> D) may goto part_fail; 

> 

mode part_fail (true) 
i 

when (true) may decision =1; status =1; 

} 

/* The template of the CPUl */ 
mode CPUl_idle (true) 
i 

when ? readyl (true) may busyl = 1; x =0; goto CPUl_InUse; 

> 

mode CPUl_InUse (x<= exe_time) 
i 

when Ifinishedl (x == exe_time) may busyl = 0; goto CPUl_idle; 

} 

mode CPU2_idle (true) 
{ 

when ? ready2 (true) may busy2 = 1; x =0; goto CPU2_InUse; 

} 

mode CPU2_InUse (x<= exe_time) 
{ 

when !finished2 (x == exe_time) may busy2 = 0; goto CPU2_idle; 

} 

/* The template of the CPUl manager */ 



mode Managerl_idle (true) 
{ 

when Treservel (true) may goto Mil; 
when ?finishedl (true) may goto M21; 

> 

mode Mil (true) 
i 

when Ireadyl (busyl ==0) may resource_grantedl =1; goto Mcinagerl_idle ; 
when (busyl ==1) may waitl =1; goto Maiiagerl_idle ; 

> 

mode M21 (true) 
{ 

when Ireadyl (waitl ==1) may waitl =0; resource_grantedl =1; goto Managerl_idle ; 
when (waitl ==0) may goto Managerl_idle ; 

> 

/* The template of the second CPU2 manager */ 

mode Mcinager2_idle (true) 

i 

when ?reserve2 (true) may goto M12; 
when ?finished2 (true) may goto M22; 

> 

mode M12 (true) 
i 

when !ready2 (busy2 ==0) may resource_graiited2 =1; goto Maiiager2_idle ; 
when (busy2 ==2) may wait2 =1; goto Manager2_idle ; 

> 

mode M22 (true) 
i 

when !ready2 (wait2 ==1) may wait2 =0; resource_grcinted2 =1; goto Manager2_idle; 
when (wait2 ==0) may goto Manager2_idle ; 

} 

We also pick some statements in the RED model in order to explain how to 
declare the model behaviour structure with RED. The declaration is a sequence 
of mode declarations. A typical mode declaration can be found from the state- 
ments (SI) to (S2). The statements declare a mode whose name is InUse and 
whose invariance condition "x<= exe_time". Inside the transition rule when we 
have a synchroniser finish, a triggering condition "x == exe_time", and the 
two actions "busy = 0" and "goto idle". The initial condition of the proto- 
col declares six processes. The first process represents the coordinator database 
server which starts at coor_idle location, the second process represents the 
participant server which starts at the part_idle location, the third and the 
fourth processes represent the CPU at each server, and finally processes 5 and 
6 represent the resource manager on each database server. 



